Problem

After a recent plugin-auth deploy that touched init_data.json (PR LerianStudio/plugin-auth#557), production applications kept their identity but lost the application↔permission associations that had been wired up via the Casdoor UI/API. The applications themselves were not deleted — only the manually-configured links to permissions disappeared.

Root cause

The plugin-access-manager Helm chart relies on Casdoor v2.206.0's default initDataNewOnly = false. With that default, every Casdoor restart re-processes the entire init_data.json and performs a DELETE + INSERT cycle on every entity that already exists in the database:

// casdoor/casdoor v2.206.0, object/init_data.go
func initDefinedApplication(application *Application) {
    existed, _ := getApplication(application.Owner, application.Name)
    if existed != nil {
        if initDataNewOnly { return }      // ← skip when true
        deleteApplication(application)     // ← delete when false (current default)
    }
    AddApplication(application)            // ← re-create from JSON
}

The same logic is mirrored in initDefinedPermission, initDefinedRole, initDefinedGroup, etc. Any field on those entities that was customized at runtime (users list, roles list, resources, permission references on an application) is silently reset to whatever is in init_data.json on every Casdoor pod restart.

This was masked in steady state because Casdoor pods were long-lived. The recent deploy forced a restart, which exposed the wipe.

Fix

Add initDataNewOnly to the auth-backend ConfigMap, parameterized via Values (default "true") to match the existing pattern on initDataFile:

  initDataFile: {{ .Values.auth.backend.initDataFile | default "./init_data.json" | quote }}
  initDataNewOnly: {{ .Values.auth.backend.initDataNewOnly | default "true" | quote }}

With initDataNewOnly: "true" Casdoor's behavior changes to:

• If an entity (owner+name) is already in the DB → SKIP (no delete, no insert, no update).
• If an entity is in the JSON but not in the DB → INSERT (still works for fresh installs and for newly added seed entries).

Operators that ever need the legacy reset-on-restart behavior can opt out per-environment by setting auth.backend.initDataNewOnly: "false" in values.

Behavior matrix

Trade-off and ops impact

• ✅ Application↔permission associations, role/user bindings, and any UI/API-managed RBAC state now survive Casdoor restarts.
• ✅ First-time installs still bootstrap correctly from init_data.json.
• ✅ Adding NEW entities to init_data.json still works on next restart (they get INSERTed).
• ⚠️ UPDATING an existing entity's actions/resources/etc. via init_data.json becomes a no-op on environments that already have it. Future updates must use the SQL migration path already in place at init/casdoor-migrations/migrations/ (which is the canonical channel — see migrations 16, 28, 29 for bank-transfer/pix-btg precedent).

Rollout plan

This PR targets develop so that the chart is released as a *-beta.N version first and validated in Firmino before promotion to main (final release).

1. Merge to develop → semantic-release publishes a vX.Y.Z-beta.N chart version
2. Firmino deploy (dev environment) → QA validates with the auth team:
   • After a Casdoor pod restart, all application↔permission associations that were configured via API/UI in the previous state are still present
   • Adding a NEW entry to init_data.json on a separate test still results in INSERT on the next pod cycle (proves seed expansion still works)
   • User → role → group → application authorization flow returns identical results before and after the chart bump
3. Once QA approves, promote develop → main (standard back-merge) to publish the release version

Operator communication

After release, any future RBAC update on an existing entity must go via SQL migration in LerianStudio/plugin-auth/init/casdoor-migrations/migrations/, not by editing init_data.json. This matches what migrations/16_add_bank_transfer_permissions.up.sql, 28_add_bank_transfer_system_config_permissions.up.sql, and 29_add_pix_indirect_btg_webhooks_operator_permissions.up.sql already model. For brand-new entities (resources/permissions/roles/groups that don't exist anywhere yet), init_data.json continues to be the right channel.

Plugin-auth side

No changes required in LerianStudio/plugin-auth:

• init/casdoor/app.conf/ in that repo is an empty directory — the Dockerfile does not copy any custom app.conf into the image
• Casdoor reads its runtime config via beego, which picks up env vars produced from this ConfigMap (envFrom: configMapRef)
• The initDataNewOnly ConfigMap key propagates directly to Casdoor as the env override

References

• Casdoor source: casdoor/casdoor@v2.206.0 object/init_data.go
• Related plugin-auth PRs that surfaced the wipe: LerianStudio/plugin-auth#557 (merged), LerianStudio/plugin-auth#558 (open)
• Casdoor docs on initDataNewOnly: https://casdoor.org/docs/deployment/server-installation